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L et's face it—we're all "difficult" at some time or 
other. This can range from mild irritability over a bad 
■ hair day, to active sabotage between competing 
groups These problems are best dealt with before they 
develop into a pattern of behavior, but the pace of 
Smalltalk development often results in people settling 
into behavioral patterns before anyone notices. 

We divide special team members into three categories: 

1. "Pluses” offer net productivity but can be much more 
productive if their unique strengths can be exploited 
while reducing the impact of their weaknesses 

2. "Zeros" are a wash and can be tolerated while your 
organization finds a place where they can become 
pluses. 

3. "M i nuses" detract from the productivity of others and 
can seriously impact a project if not dealt with in some 
way. 

Keep in mind that we are writing about established be¬ 
havior patterns here. Obviously, new assignments, emo¬ 
tional problems, family crises, etc., make the best of us 
"zeros" or even "minuses” from time to time, and a com¬ 
passionate organization will help, or at least tolerate, 
these non-chronic productivity losses. 

Here are some of the more prevalent behavior patterns 
we’ve found in Smalltalk projects and suggestions for 
dealing with them. 

'THE LONER" 

This person is an enigma to management, the Loner is 
often a Meyers—Briggs 1 "INTP" type, who may be per¬ 
ceived as "not a team player," and might even be fired if 
he wasn’t so damned creative. Like Bramson's 2 "Analyst," 
the Loner will often miss deadlines, not because he isn’t 
working, but simply because he is st/7/ working! 

The big danger on a Smalltalk project is that the Loner 
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may disappear after having been given an assignment 
and come up for air several months later with a beautiful¬ 
ly crafted, complete solution to the wrong problem. 
Because Smalltalk is so productive, it may be tempting to 
redefine the project around the Loner’s wonderful solu¬ 
tion of the wrong problem, because he may well be far 
ahead of the rest of the team, who’ve been busy collabo¬ 
rating all these months! 

At worst, a single Loner is a "zero," but two or more on 
a team may quickly destroy a project if not guided by 
a skilled architect. Once you’ve discovered a Loner on 
your team, there are several techniques you can use to 
harvest his creativity without yielding control of the 
project: 

• Schedule regular peer review, especially at the design 
level, before the Loner isableto write reams of code. 

•If the Loner is also a Know-It-All (discussed later), call 
these peer reviews "educational reviews" to avoid 
wounding his fragile ego. 

• Assign the Loner a "shadow,” "buddy,” or "stunt-double" 
—someone who keeps up-to-date on what the Loner is 
doing, in case it is necessary to fill in in an emergency 
and provide the communication that the Loner is unable 
to provide. 

• Limit Loners to well-specified, well-defined tasks. This 
is a last resort, because junior people will not break 
their Loner habit and senior people will get bored and 
possibly become Slackers (discussed later). 

'THE LOANER" 

While discussing the Loner, we realized we have, on sev¬ 
eral occasions, experienced its pun! For various reasons, 
the project is running late and senior management 
decides they had better round up nine peopleso they can 
ship this baby in a month. 

Almost 20 years ago, Frederick Brooks, J r. 3 noticed that 
adding resources to a late project makes it even later. 
Loaners often consume more time than they add, and 
are, therefore, "minuses," because they need to be inte¬ 
grated with the team’s procedures and conventions, and 
also absorb all the history that has gone into getting to 
thispoint ofcrisis.Thisisnotso much a reflection on the 
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person as it ison the process that put them inthisunfor- 
tunate situation. 

This problem is amplified by Smalltalk because 
Smalltalk is not a language, it is an environment. Not only 
must this person learn your project before they can be 
useful, they often must learn exotic (to them) concepts, 
such as Dictionaries—concepts for which your team has 
developed a shared vision. 

Even more insidious is the possibility that you might 
not be getting quality material to begin with. Thinkof it— 
if asked to loan one of your team members, would you 
give your best person, or perhaps someone whom you 
haven’t quite been able to find a place for yet? 

If your manager insists on doing 
you this "favor," keep the following 
in mind: 

• Make sure they are doing you a 
favor—don't accept someone 
else’s problem when you’re al¬ 
ready in scheduletrouble! 

•Keep loan lengths on the long 
side to better amortize the "in¬ 
terest" cost of borrowing a per¬ 
son—don't take a Loaner for less 
than six months, unless the per¬ 
son has enough history with your project to hit the 
ground running. 

•Your Loaner must either be Smalltalk-knowledgeable, or 
must be able to contribute without ever touching 
Smalltalk. Growing Smalltalk talent is too much of an 
investment to return when the loan is due! 

• M ake sure Loaners document their work so others can 
pi ck u p where they I eave off. 

•Assign them a "stunt double," who will work with them 
on a day-to-day basis. (Be aware that too much "time 
suckage" from the double may turn a Loaner into a 
"minus”) 

'THE COWBOY" 

The Cowboy typically learned Smalltalk in relative iso¬ 
lation and is used to being "king of the image". Cowboys 
delight in tricky code, sometimes doing it for sheer intel¬ 
lectual pleasure without the slightest rationale. 

The Cowboy’s nemesis is ENVY/Developer, because 
he doesn’t like people looking at his tricky code, he can’t 
imagine others actually working on his tricky code, and 
absolutely hates the constraints imposed by a code 
management system—if changing the implementation 
of basicNew suits his purpose, he cannot tolerate the 
thought of getting the permission of the Library 
Supervisor! 

Cowboys can be wonderful "pluses" if carefully man¬ 
aged; they can also be "minuses" if they consistently de- 
stabiIize your envi ronment or if thei r escapades consume 
an entire "stunt-double" resource. To deal with the Cow¬ 
boy, try the fol lowi ng: 

• Use and enforce your code management system’s se- 
cu ri ty featu res. Th i s i ncl udes passwords for al I accou nts 


and no shared accounts, especially privileged accounts 
such as ENVY’s Library Supervisor. 

Never, ever let the Cowboy use a privileged account to 
work on the base i mage! 

Find tasks for Cowboys that exploit their curious 
nature—some tasks demand tricky code! 

Establ ish a cuIture where the only tricky code tolerated 
is well documented, complete with the rationale for 
being tricky. 

The Cowboy is often a Loner, and some of those coping 
strategies, such as extensive peer-review and "stunt- 
double" coverage, work well for him also. 

'THE SLACKER"OR "ROBINSON 
CRUSOE" 

The Slacker often knows the best 
web sites and is fluent on the latest 
Usenet newsgroup gossip. He may 
often quickly collapse a window as 
you approach his desk and you may 
notice his long print jobs that are 
totally unrelated to work. When 
others are at his desk, they often 
seem to be doing the typing or 
mousing. 

We sometimes call this pattern "Robinson Crusoe" be¬ 
cause it seems that Slackers always expect to have their 
work done by Friday, even though they haven’t started it by 
Thursday. (And if on Friday they are i neon veniently strand¬ 
ed on some desert isle, Slackers are perfectly content to 
arrange for other team members to pick up the slack!) 

The Slacker never meets a deadline and never works 
a full week, but neither does he ever report that he is 
behind schedule and, of course, there is always "The 
Good Excuse.” 

Slackers come in two varieties: Dumb and Lazy, and 
Bored. It is difficult to distinguish between them but the 
difference is vital: 

•A Dumb and Lazy Slacker is in over his head but won't 
admit it and doesn’t real ly care. He may become a mi nor 
"plus” if given a simpler task. 

•A Bored Slacker is in well under his head and may 
become a major "plus" if properly i nspired. 

If you do not raise The Slacker to at least a "zero," your 
project will suffer much more than the mere loss of effective 
head count. Sometimes you can do this by the fol lowing: 

•Give Slackers additional training or mentoring. Put a 
hard limit on this "ti me suckage,” and let Slackers know 
it or thei r mentors will merely end u p doi ng al I the work. 

•Give Slackers many intermediate deliverables, which 
may help determine whether they are Dumb and Lazy 
or merely Bored. 

• M icromanage the Slackers with daily progress checks, 
but recognize that this activity alone may take enough 
of yourtimeto keep them a"minus” 

Often, despite your best efforts, a Dumb and Lazy Slacker 
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cannot be raised to a "plus." This cannot be tolerated and 
the person must go. If removinga Dumb and Lazy Slacker 
from your project is not possible, you need to minimize 
his impact on your team. 

• Isolate the Slacker; forbid him to seek help, and forbid 
others to help him with his work. 

• Perhaps you can turn your Slacker into someone else’s 
Loaner? (Nah, we wouldn't suggest that!) 

'THE KNOW-IT-ALL" 

This person often actually knows a lot, but the Know-It- 
All's insecurity causes them to "know" more than they 
actually do. (In the immortal words of Bo Didley, "It ain’t 
what you don’t know; it's what you know that just ain't 
so!") We’ve found this often results from taking someone 
who has been the"big cheese" on a traditional project and 
immersing them in Smalltalk, which is strange, different, 
and frightening to someone who has become used to 
being an acknowledged expert. 

This is the only pattern that Bramson also uses, and he 
divides them into two categories: the "Bulldozers" and 
"Balloons," the primary difference being that"Bulldozers” 
know what they’re talking about whereas "Balloons" do 
not. Of the two, "Bulldozers" are merely obnoxious— 
although they may demoralize others with their strong 
asserti ons, they are sti 11 strong "pi uses," even i n context of 
the entire team. We’re more concerned with "Balloons," 
who can lead an entire project astray if they have the ear 
of someone important! 

Don't let the insecurity of the Know-It-Alls blind you 
to what they can be contributing. To deal with the Know- 
It-All try the following: 

• Be quick to acknowledge and reward the greatness of 
Know-It-Alls when you know they are right—give them 
strokes freely when they deserve it and they will be 
less likely to seek strokes for false knowledge. 

•Ease Know-It-Alls out of their comfort zone—carve 
off a bit of the project, such as designing C primi¬ 
tives or RDBMS access, which will allow them to use 
their expertise while slowly coming to grips with 
Smalltalk. 

•A Know-It-All can be responsible about his or her lack 
of knowledge when not threatened and may do well 
if assigned a junior "buddy" to mentor. The mentoring 
can surreptitiously become two-way, especially if the 
junior person is farther along the Smalltalk learning 
curve, but monitor them carefully to make sure The 
Know-It-All is not filling an impressionable mind with 
puffery. 

CONCLUSION 

There are very few truly useless people in this world, but 
there are many people who are viewed in light of their 
weaknesses, rather than being put to work using their 
strengths. 

As Smalltalk amplifies this problem, an out-of-place 
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continued from page 14 

enough decisions to be able to work, but few enough that 
our code doesn’t become brittle. That’s one of the things 
that makes software difficult. 

Passing off decisionsto another object isoften referred 
to as using policy or strategy objects. This is discussed in 
Design Patterns 1 as the Strategy pattern. 

Other related ideas are "Open Implementations,” which 
can allow important decisionsto be postponed so far that 
even the end user of the module can control them. I can’t 
do justice to this topic here, but there’s a web page avail¬ 
able at http://www.xerox.com/PARC/spl/eca/oi.html 
Because web pages change so rapidly, I’ll also mention 
that I found it using the search terms open implementa¬ 
tion and Gregor Kiczaies (the project leader). 

POSTSCRIPT 

Although there is a significant element of humor in these 
principles, I do take them quite seriously and urge you to 
do the same. They i llustrate some very important aspects 
of 00 design and codi ng. I've even come up with enough 
ofthemtofill another column, so the next issue will con- 
tinuethistheme. ffi 
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person can cause damage more quickly on a Smalltalk 
project than they can on a traditional project, and corpo¬ 
rate cultural checks that normally help such people, such 
as peer reviews, management one-on-one meetings, and 
performance reviews, are tuned to the slower beat of the 
traditional project. 

Beginning a Smalltalk project offers the opportunity 
for a "behavioral context switch,” in which old patterns 
can be broken. By catching behavioral difficulties early, 
you can keep them from becoming established patterns. 
Once behavioral patterns are established, their impact 
on productivity must be carefully monitored and hu¬ 
manely dealt with. ffi 
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